home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / rfc / rfc1328 < prev    next >
Encoding:
Text File  |  1992-05-18  |  9.8 KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                S. Hardcastle-Kille
  8. Request for Comments: 1328                     University College London
  9.                                                                 May 1992
  10.  
  11.  
  12.                      X.400 1988 to 1984 downgrading
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC specifies an IAB standards track protocol for the Internet
  17.    community, and requests discussion and suggestions for improvements.
  18.    Please refer to the current edition of the "IAB Official Protocol
  19.    Standards" for the standardization state and status of this protocol.
  20.    Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This document considers issues of downgrading from X.400(1988) to
  25.    X.400(1984) [MHS88a, MHS84].  Annexe B of X.419 specifies some
  26.    downgrading rules [MHS88b], but these are not sufficient for
  27.    provision of service in an environment containing both 1984 and 1988
  28.    components.  This document defines a number of extensions to this
  29.    annexe.
  30.  
  31.    This specification is not tutorial.  COSINE Study 8.2 by J.A.I.
  32.    Craigie gives a useful overview [Cra88].
  33.  
  34. 1.  The need to Downgrade
  35.  
  36.    It is expected that X.400(1988) systems will be extensively deployed,
  37.    whilst there is still substantial use of X.400(1984).  If 1988
  38.    features are to be used, it it important for there to be a clear
  39.    approach to downgrading.  This document specifies an approach to
  40.    downgrading for the Internet and COSINE communities.  As 1988 is a
  41.    strict superset of 1984, the mapping is a one-way problem.
  42.  
  43. 2.  Avoiding Downgrading
  44.  
  45.    Perhaps the most important consideration is to configure systems so
  46.    as to minimise the need for downgrading.  Use of 1984 systems to
  47.    interconnect 1988 systems should be strenuously avoided.
  48.  
  49.    In practice, many of the downgrading issues will be avoided.  When a
  50.    1988 originator sends to a 1984 recipient, 1988 specific features
  51.    will not be used as they will not work!  For distribution lists with
  52.    1984 and 1988 recipients, messages will tend to be "lowest common
  53.    denominator".
  54.  
  55.  
  56.  
  57.  
  58. Hardcastle-Kille                                                [Page 1]
  59.  
  60. RFC 1328             X.400 1988 to 1984 downgrading             May 1992
  61.  
  62.  
  63. 3.  Addressing
  64.  
  65.    In general there is a problem with O/R addresses which use 88
  66.    specific features.  The X.419 downgrade approach will mean that
  67.    addresses using these features cannot be specified from 84 systems.
  68.    Worse, a message originating from such an address cannot be
  69.    transferred into X.400(1984).  This is unacceptable.  Two approaches
  70.    are defined.  The first is a general purpose mechanism, which can be
  71.    implemented by the gateway only.  The second is a special purpose
  72.    mechanism to optimise for a form of X.400(88) address which is
  73.    expected to be used frequently (Common Name).  The second approach
  74.    requires cooperation from all X.400(88) UAs and MTAs which are
  75.    involved in these interactions.
  76.  
  77. 3.1  General Approach
  78.  
  79.    The first approach is to use a DDA "X400-88".  The DDA value is an
  80.    std-or encoding of the address as defined in RFC 1327 [Kil92].  This
  81.    will allow source routing through an appropriate gateway.  This
  82.    solution is general, and does not require co-operation.  For example:
  83.  
  84. 88:
  85.      PD-ADDRESS=Empire State Building;  PRMD=XX; ADMD=ZZ; C=US;
  86.  
  87. 84:
  88.      O=MHS-Relay; PRMD=UK.AC; C=GB;
  89.      DD.X400-88=/PD-ADDRESS=Empire State Building/PRMD=XX/ADMD=ZZ/C=US/;
  90.  
  91.    The std-or syntax can use IA5 characters not in the printable string
  92.    set (typically to handle teletext versions).  To enable this to be
  93.    handled, the std-or encoded in encapsulated into printable string
  94.    using the mappings of Section 3.4 of RFC 1327.  Where the generated
  95.    address is longer than 128 characters, up to three overflow domain
  96.    defined attributes are used:  X400-C1; X400-C2; X400-C3.
  97.  
  98. 3.2  Common Name
  99.  
  100.    Where a common name attribute is used, this is downgraded to the
  101.    Domain Defined Attribute "Common".  For example:
  102.  
  103.    88:
  104.        CN=Postmaster; O=A; ADMD=B; C=GB;
  105.  
  106.    84:
  107.        DD.Common=Postmaster; O=A; ADMD=B; C=GB;
  108.  
  109.    The downgrade will always happen correctly.  However, it will not
  110.    always be possible for the gateway to do the reverse mapping.
  111.  
  112.  
  113.  
  114. Hardcastle-Kille                                                [Page 2]
  115.  
  116. RFC 1328             X.400 1988 to 1984 downgrading             May 1992
  117.  
  118.  
  119.    Therefore, this approach requires that all 1988 MTAs and UAs which
  120.    wish to interact with 1984 systems through gateways following this
  121.    specification will need to understand the equivalence of these two
  122.    forms of address.
  123.  
  124. 4.  MTS
  125.  
  126.    Annexe B of X.419 is sufficient, apart from the addressing.
  127.  
  128.    The discard of envelope fields is unfortunate.  However, the
  129.    criticality mechanism ensures that no information the originator
  130.    specifies to be critical is discarded.  There is no sensible
  131.    alternative.  If mapping to a system which support the MOTIS-86 trace
  132.    extensions, it is recommended that the internal trace of X.400(88) is
  133.    mapped on to this, noting the slight differences in syntax.
  134.  
  135. 5.  IPM Downgrading
  136.  
  137.    The IPM service in X.400(1984) is usually provided by content type 2.
  138.    In many cases, it will be useful for a gateway to downgrade P2 from
  139.    content type 22 to 2.  This will clearly need to be made dependent on
  140.    the destination, as it is quite possible to carry content type 22
  141.    over P1(1984).  The decision to make this downgrade will be on the
  142.    basis of gateway configuration.
  143.  
  144.    When a gateway downgrades from 22 to 2, the following should be done:
  145.  
  146.    1.  Strip any 1988 specific headings (language indication, and
  147.        partial message indication).
  148.  
  149.    2.  Downgrade all O/R addresses, as described in Section 3.
  150.  
  151.    3.  If a directory name is present, there is no method to preserve
  152.        the semantics within a 1984 O/R Address.  However, it is
  153.        possible to pass the information across, so that the information
  154.        in the Distinguished Name can be informally displayed to the
  155.        end user.  This is done by appendend a text representation of
  156.        the Distinguished Name to the Free Form Name enclosed in round
  157.        brackets.  It is recommended that the "User Friendly Name"
  158.        syntax is used to represent the Distinguished Name [Kil90].  For
  159.        example:
  160.  
  161.        (Steve Hardcastle-Kille, Computer Science,
  162.         University College London, GB)
  163.  
  164.    4.  The issue of body part downgrade is discussed in Section 6.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Hardcastle-Kille                                                [Page 3]
  171.  
  172. RFC 1328             X.400 1988 to 1984 downgrading             May 1992
  173.  
  174.  
  175. 5.1  RFC 822 Considerations
  176.  
  177.    A message represented as content type 22 may have originated from RFC
  178.    822 [Cro82].  The downgrade for this type of message can be improved.
  179.    This is discussed in RFC 1327 [Kil92].
  180.  
  181. 6.  Body Part downgrading
  182.  
  183.    The issue of body part downgrade is very much linked up with the
  184.    whole issue of body part format conversion.  If no explicit
  185.    conversion is requested, conversion depends on the MTA knowing the
  186.    remote UA's capabilities.  The following options are available for
  187.    body part conversion in all cases, including this one.  It is assumed
  188.    that body part conversion is avoided where possible.
  189.  
  190.    1.  Downgrade to a standard 1984 body part, without loss of
  191.        information
  192.  
  193.    2.  Downgrade to a standard 1984 body part, with loss of information
  194.  
  195.    3.  Discard the body part, and replace with a (typically IA5 text)
  196.        message.  For example:
  197.  
  198.        **********************************************
  199.        *
  200.        *  There was a hologram here which could
  201.        *  not be converted
  202.        *
  203.        **********************************************
  204.  
  205.    4.  Bounce the message
  206.  
  207.    If conversion is prohibited, 4) must be done.  If conversion-with-
  208.    loss is prohibited, 1) should be done if possible, otherwise 4).  In
  209.    other cases 2) should be done if possible.  If it is not possible,
  210.    the choice between 3) and 4) should be a configuration choice.  X.419
  211.    only recognises 4).  3) Seems to be a useful choice in practice,
  212.    particularly where the message contains other body parts.  Another
  213.    option is available when downgrading:
  214.  
  215.       1.  Encapsulate the body part as a Nationally Defined 1984
  216.           body part (body part 7).
  217.  
  218.    This should be used when configured for the recipient UA.
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Hardcastle-Kille                                                [Page 4]
  227.  
  228. RFC 1328             X.400 1988 to 1984 downgrading             May 1992
  229.  
  230.  
  231. References
  232.  
  233.    [Cra88]  Craigie, J., "Migration strategy for x.400(84) to
  234.             x.400(88)/MOTIS", COSINE Specification Phase 8.2, RARE, 1988.
  235.  
  236.    [Cro82]  Crocker, D., "Standard of the Format of ARPA Internet Text
  237.             Messages", RFC 822, UDEL, August 1982.
  238.  
  239.    [Kil90]  Kille, S., "Using the OSI directory to achieve user friendly
  240.             naming", Research Note RN/90/29, Department of Computer
  241.             Science, University College London, February 1990.
  242.  
  243.    [Kil92]  Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC
  244.             822", RFC 1327, University College London, May 1992.
  245.  
  246.    [MHS84]  Recommendations X.400, October 1984. CCITT SG 5/VII, Message
  247.             Handling Systems:  System Model - Service Elements.
  248.  
  249.    [MHS88a] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
  250.             SG 5/VII / ISO/IEC JTC1, Message Handling:  System and
  251.             Service Overview.
  252.  
  253.    [MHS88b] CCITT recommendations X.419/ ISO 10021, April 1988.
  254.             CCITT SG 5/VII / ISO/IEC JTC1, Message Handling:  Protocol
  255.             Specifications.
  256.  
  257. 7.  Security Considerations
  258.  
  259.    Security issues are not discussed in this memo.
  260.  
  261. 8.  Author's Address
  262.  
  263.    Steve Hardcastle-Kille
  264.    Department of Computer Science
  265.    University College London
  266.    Gower Street
  267.    WC1E 6BT
  268.    England
  269.  
  270.    Phone:  +44-71-380-7294
  271.    EMail:  S.Kille@CS.UCL.AC.UK
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Hardcastle-Kille                                                [Page 5]
  283.  
  284.